\chapter{Requirements}
\label{chap:req}
\section{Functional Requirements}
Here is a list of functions that the product must, or may, have:
\begin{enumerate}
\item The product must be configurable from outside of the product.
\item The user must be able to specify which package the product will run over.
\item The user must be able to define which aspect is active.
\item The user must be able to specify where the log file will be outputted to.
\item The user should be able to decide upon what sort of graph is drawn.
\item The user should be able to decide upon the data used to draw the graph.
\item The product should contain a variety of aspects.
\item There must be an aspect that times how long each method within a package runs.
\item There should be an aspect that counts the number of times that each method is touched.
\item The product must be able to deal with multi-threaded applications.
\end{enumerate}
\newpage
\subsection{Configurable}
\label{sec:conf}
The product must be configurable. If the user is unable to configure the product, there is little point in it. The user would be unable to set it for their system, and would be unable to get any data from it. Below, I have specified the parts of the product that must be configurable.

The user must be able to specify which package the product will run over. This is perhaps the most important configurable option at the users disposal. If the user were unable to choose the package to run over, the product would have a very limited usefulness. It would be nice if the user were able to specify multiple packages to run over, but this is not a requirement.

The user must be able to define which aspect is active. Having multiple aspects active at one time may be a possibility, however it is not a requirement. At least 1 aspect must be active at all times. This should be relatively simple enough to change. The output file should also be formatted correctly, given the choice, or choices, of aspect. The data would be useless if the user is unable to read it.

The user must be able to specify where the log file will be outputted to. This is so the user may choose to put it in a pre-defined log folder, or a different place entirely. The user may wish to separate the log generated by this product with the logs relating to their application. Similarly, they may wish for all output to go to a common place.

The user should be able to decide upon what sort of graph is drawn, and the data used to draw the graph. This allows the user to get a graphical representation of whatever it is they wish to see. The visual software would not be useful if it cannot be configured to show what the user wants.

\subsection{Aspects}
There should be a variety of aspects available to the user, in order to prove that multiple aspects can be made, and used, within this product. These aspects must do distinct, useful operations that can plot different sets of information. It would be nice if each aspect were internally configurable, though this is not a requirement.

There must be an aspect that times how long each method within a package runs. This is, perhaps, the most useful aspect for this product, as it is the simplest way to find a bottleneck within the code, which directly links with the problem defined within Chapter~\ref{chap:prodef} - \nameref{chap:prodef}.

There should be an aspect that counts the number of times that each method is touched, and orders the results by this number. Potential configurations could be related to how this aspect deals with multi-threaded applications, as to whether it sums all uses of a method, or has a different set of data for each thread. As previously stated, however, the configurability of an aspect is not a requirement.

It would be nice to have an aspect that regularly checks the heap size, or the stack depth of the code, at various points in the code, however these are not a requirement. The code should, however, be structured in such a way that additions of this nature would be relatively simple to implement.
\newpage
\subsection{Multi-thread}
The product must be able to deal with multi-threaded applications. The product should not be limited to single-threaded applications. Generally, with a higher complexity of application, the difficulty in finding where the bottleneck is will also increase. This is especially true for multi-threaded applications, as it is not always obvious in which order things may execute, nor how long a thread may take to finish its task.

It would also be nice if it could give data from each thread separately, as detailed above. This would allow two potential views for the data. The total view, for seeing if a particular thread is going slowly, and a thread view, which would allow the user to see the individual operations run by the thread. However, implementing this is not a requirement.
\newpage
\section{Non-functional Requirements}
Here is a list of the non-functional requirements that the product must, or may, fulfil:
\begin{enumerate}
\item The product must have no, or very little, impact upon the runtime of the application.
\item The product should be relatively easy to extend.
\item The output files (logs and graphs) should be readable and easily understandable.
\end{enumerate}
\subsection{Runtime}
There must be a very low impact on the application's runtime. The amount of time from start to finish may increase, but the time spent within the application's code should be altered as little as possible.

\subsection{Extensibility}
Given the framework, it should be rather simple to extend the project to include other aspects, as the user requests. The structure should allow for any potential aspect the user may wish for.

\subsection{Readability}
The output files should be readable for the same reasons specified in Section~\ref{sec:conf}. ``The data would be useless if the user is unable to read it.''
